shared/utils/constants.ts (1)

19-21: Consider making the leaderboard API URL configurable via runtime config.

LIKES_LEADERBOARD_API_URL hardcodes a third-party Railway deployment URL. If the API host ever moves (different region, custom domain, staging environment, or a self-hosted alternative), this will require a code change and redeploy. Exposing it via runtimeConfig.public (with this constant as the default) would give operators a runtime escape hatch.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@shared/utils/constants.ts` around lines 19 - 21, The constant
LIKES_LEADERBOARD_API_URL hardcodes a deployment URL; change it to be
configurable at runtime by reading a public runtime config value (e.g.
runtimeConfig.public.likesLeaderboardApiUrl) with the existing string as the
default. Replace the exported constant with a getter (or export a function like
getLikesLeaderboardApiUrl) that returns
runtimeConfig.public.likesLeaderboardApiUrl ||
'https://npmx-likes-leaderboard-api-production.up.railway.app/api/leaderboard/likes',
and update all call sites that import LIKES_LEADERBOARD_API_URL to call the
getter/function instead so operators can override the URL without redeploying.
Ensure you reference runtime config APIs used by your app (e.g.,
useRuntimeConfig or access process.env if appropriate) when implementing the
getter.

i18n/locales/en.json (1)

801-801: Hardcoded 10 in description couples copy to API limit.

"The 10 most liked packages on npmx right now." hardcodes the leaderboard size. If the ?limit=10 constant is ever changed (or made configurable), this string will go out of sync silently. Consider parameterising with a {count} placeholder driven by the same source as the API request.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@i18n/locales/en.json` at line 801, The description string "The 10 most liked
packages on npmx right now." hardcodes the leaderboard size; replace it with a
parameterised placeholder like "{count}" and wire the same count value used by
the API request (the limit query param or limit constant) into the i18n
formatter so the displayed number comes from the same variable that sets
?limit=10; update the locale key (the "description" entry) and ensure the
view/controller that builds the request passes that count into the i18n
translate/format call so the text and the API request remain in sync.

server/api/social/likes/[...pkg].get.ts (1)

27-36: Parallel fetch reads cleanly; relies on getTopLikedRank never throwing.

The current getTopLikedRank implementation is safe (it bottoms out in getLikesLeaderboard's try/catch returning null), so Promise.all won't reject due to leaderboard failures. If a future refactor ever lets getTopLikedRank throw, likes responses would 502 — consider Promise.allSettled or a local try/catch around the rank fetch to harden the contract that the rank is "best-effort, never blocks likes".

♻️ Optional defensive variant

-    const [likes, topLikedRank] = await Promise.all([
-      likesUtil.getLikes(packageName, oAuthSession?.did.toString()),
-      getTopLikedRank(event, PACKAGE_SUBJECT_REF(packageName)),
-    ])
-
-    return {
-      ...likes,
-      topLikedRank,
-    }
+    const [likesResult, rankResult] = await Promise.allSettled([
+      likesUtil.getLikes(packageName, oAuthSession?.did.toString()),
+      getTopLikedRank(event, PACKAGE_SUBJECT_REF(packageName)),
+    ])
+    if (likesResult.status === 'rejected') throw likesResult.reason
+    return {
+      ...likesResult.value,
+      topLikedRank: rankResult.status === 'fulfilled' ? rankResult.value : null,
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/social/likes/`[...pkg].get.ts around lines 27 - 36, The current
parallel fetch uses Promise.all with likesUtil.getLikes and getTopLikedRank
which assumes getTopLikedRank never throws; make the rank fetch best-effort so
failures don’t cause the whole handler to 502 by wrapping the rank call in a
protective construct (either use Promise.allSettled for the two promises and
extract a successful topLikedRank or null on rejection, or perform a separate
try/catch around await getTopLikedRank(event, PACKAGE_SUBJECT_REF(packageName))
and set topLikedRank = null on error); keep likesUtil.getLikes
(PackageLikesUtils) awaited normally and return the combined result with
topLikedRank defaulting to null on failure.

server/api/leaderboard/likes.get.ts (1)

5-10: Consider falling back to unenriched entries on enrichment failure.

If enrichLikesLeaderboardEntries rejects (e.g. one of the per-entry homepage/stars fetches throws and isn't internally caught), the entire endpoint errors and the page loses data we already successfully fetched from the upstream leaderboard. A small wrapper around the enrichment call would let you serve raw entries as a graceful fallback, matching the PR's stated "degrade gracefully" intent.

♻️ Suggested fallback

-  const leaderboardEntries = await getLikesLeaderboard(event)
-  if (!leaderboardEntries) return []
-
-  return await enrichLikesLeaderboardEntries(event, leaderboardEntries)
+  const leaderboardEntries = await getLikesLeaderboard(event)
+  if (!leaderboardEntries) return []
+
+  try {
+    return await enrichLikesLeaderboardEntries(event, leaderboardEntries)
+  } catch (err) {
+    console.error('[leaderboard/likes] Enrichment failed, returning raw entries:', err)
+    return leaderboardEntries
+  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/leaderboard/likes.get.ts` around lines 5 - 10, The endpoint
currently calls enrichLikesLeaderboardEntries(event, leaderboardEntries) and
will error the whole request if enrichment rejects; wrap that call in a
try/catch so you return the raw leaderboardEntries on enrichment failure.
Specifically, in the eventHandler after getLikesLeaderboard returns entries,
call enrichLikesLeaderboardEntries inside a try block and return its result if
successful, but on catch log the error (or processLogger/error) and return
leaderboardEntries as the graceful fallback; keep the initial
getLikesLeaderboard and the function signatures unchanged.

server/utils/likes-leaderboard.ts (2)

90-156: Reduce duplication and length in getLeaderboardEntryMetadata.

The function is 67 lines (above the ~50-line guideline) primarily because the same return object shape is built three times (lines 124–129, 134–139, 142–147). Collapsing it into a single return with the GitHub ref derived inline keeps all field assignments in one place and shrinks the function meaningfully.

♻️ Suggested shape

-    if (!rawRepositoryUrl) {
-      return {
-        packageDescription,
-        weeklyDownloads,
-        homepageUrl,
-        githubRepositoryRef: null,
-      }
-    }
-
-    const repositoryRef = parseRepoUrl(rawRepositoryUrl)
-    if (!repositoryRef || repositoryRef.provider !== 'github') {
-      return {
-        packageDescription,
-        weeklyDownloads,
-        homepageUrl,
-        githubRepositoryRef: null,
-      }
-    }
-
-    return {
-      packageDescription,
-      weeklyDownloads,
-      homepageUrl,
-      githubRepositoryRef: repositoryRef,
-    }
+    const repositoryRef = rawRepositoryUrl ? parseRepoUrl(rawRepositoryUrl) : null
+    return {
+      packageDescription,
+      weeklyDownloads,
+      homepageUrl,
+      githubRepositoryRef:
+        repositoryRef?.provider === 'github' ? repositoryRef : null,
+    }

As per coding guidelines: "Keep functions focused and manageable (generally under 50 lines)".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/utils/likes-leaderboard.ts` around lines 90 - 156, The
getLeaderboardEntryMetadata function duplicates the same return shape three
times; refactor it to build all fields once and return a single object: compute
encodedPackageName, packument, downloadsResult and parsedDownloads as now,
derive rawRepositoryUrl and let repositoryRef = rawRepositoryUrl ?
parseRepoUrl(rawRepositoryUrl) : null, then set githubRepositoryRef =
repositoryRef && repositoryRef.provider === 'github' ? repositoryRef : null and
return { packageDescription, weeklyDownloads, homepageUrl, githubRepositoryRef }
in one place (keeping the existing try/catch and use of cachedFetch,
NpmDownloadCountSchema and encodePackageName).

---

41-50: Regex matches sub-paths; consider tightening.

^https://npmx\.dev/package/(.+)$ will accept https://npmx.dev/package/foo/extra/segments and capture the entire trailing portion as the package name. This would only matter if upstream ever returns malformed/extra-segmented subjectRef values, but a stricter pattern (e.g. capturing only @scope/name or unscoped names) plus an explicit reject for unexpected trailing characters would fail loudly rather than silently produce a junk packageName. Optional given the controlled upstream contract.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/utils/likes-leaderboard.ts` around lines 41 - 50, The regex in
extractPackageNameFromSubjectRef is too permissive and will capture extra path
segments; tighten it to only accept valid npm package names (either unscoped
[^/]+ or scoped `@scope/name`) and reject any trailing characters so malformed
subjectRef like /package/foo/extra are not accepted; update the pattern used in
extractPackageNameFromSubjectRef to match either `@scope/name` or name (e.g.
^https://npmx\.dev/package/(@[^/]+\/[^/]+|[^/]+)$) and keep the existing
decodeURIComponent/try-catch logic for returning the package name or null on
non-match.

app/pages/leaderboard/likes.vue (2)

119-119: Minor: prefer numeric v-for over hardcoded arrays.

Vue's v-for="n in 3" iterates n = 1, 2, 3 and avoids allocating a literal array on every render. For the 4–10 range you can use v-for="n in 7" and key on n + 3, or Array.from({ length: 7 }, (_, i) => i + 4).

♻️ Proposed tweak

-          <li v-for="rank in [1, 2, 3]" :key="rank" class="space-y-4">
+          <li v-for="rank in 3" :key="rank" class="space-y-4">

-          <li v-for="rank in [4, 5, 6, 7, 8, 9, 10]" :key="rank">
+          <li v-for="i in 7" :key="i + 3">
+            <!-- use (i + 3) wherever `rank` was referenced -->

Also applies to: 166-166, 214-214

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/leaderboard/likes.vue` at line 119, Replace the hardcoded array
v-for uses with numeric v-for to avoid allocating arrays on each render: change
the top-three loop to v-for="rank in 3" and keep :key="rank"; for the 4–10 block
replace the array with v-for="n in 7" and compute the displayed rank and key as
n + 3 (or use a computed value) so keys remain unique; make the same replacement
for the other two occurrences mentioned (the blocks at the other v-for
locations) ensuring you update any template expressions that referenced the
original array values to use the new loop variable arithmetic.

---

281-461: Consider extracting the podium card to remove ~180 lines of duplication.

The mobile (lg:hidden) and desktop (hidden lg:grid) podium <ol> blocks render identical card content for highlightedEntries; only the outer list classes and getPodiumItemClass differ. The same duplication exists in the skeleton section (lines 118–160 vs. 162–211). Extracting the per-entry card into a small <PodiumCard> (or a v-slot-driven sub-component) would cut the template roughly in half and make future changes (e.g. metric tweaks, i18n strings) only need to be applied in one place.

Note: The current setup does also have all top-3 metric/title strings duplicated three times, so any tweak (e.g. changing text-xs → text-sm) is currently a four-place edit (mobile data, desktop data, mobile skeleton, desktop skeleton).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/leaderboard/likes.vue` around lines 281 - 461, The template
duplicates the entire per-entry card for mobile and desktop (and their
skeletons); extract the repeated card into a new PodiumCard component (or
functional sub-component) that accepts props like entry (or packageName,
homepagePreviewUrl, homepagePreviewWidth/Height, repositoryStars,
weeklyDownloads, totalLikes, rank) and exposes a slot for skeleton rendering;
keep the outer <li> wrapper (where getPodiumItemClass(entry.rank) is applied) in
the parent lists and replace the repeated BaseCard/inner markup with <PodiumCard
:entry="entry" :rank="entry.rank" :to="packageRoute(entry.packageName)" /> (and
use the same for skeletons), ensuring PodiumCard uses compactNumberFormatter,
formatCompactStat and $t internally so metric/i18n changes are centralized.

server/utils/npm-homepage.ts (1)

95-97: Consider logging unexpected Microlink errors for observability.

The bare catch {} swallows everything — including timeouts and unexpected runtime errors — without any signal. The sibling utility in server/utils/likes-leaderboard.ts (lines 207–213) uses console.error('[likes-leaderboard] Failed to fetch likes leaderboard:', ...) for symmetry; consider matching that here so silent Microlink outages are diagnosable in production logs.

📝 Optional logging

-  } catch {
+  } catch (err) {
+    console.error(
+      '[npm-homepage] Failed to fetch homepage metadata:',
+      err instanceof Error ? err.message : 'Unknown error',
+    )
     return emptyHomepageMetadata(homepageUrl)
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/utils/npm-homepage.ts` around lines 95 - 97, The empty catch in
server/utils/npm-homepage.ts swallows Microlink errors; change it to catch the
error (e) and log it before returning emptyHomepageMetadata(homepageUrl), e.g.
use console.error with a clear prefix like '[npm-homepage] Failed to fetch
Microlink:' and include the error object so outages/timeouts are observable;
keep the return of emptyHomepageMetadata(homepageUrl) unchanged.

test/unit/server/utils/likes-leaderboard.spec.ts (1)

280-295: Add coverage for getTopLikedRank null/no-match paths.

The single test only covers a happy-path match. Worth adding cases for:

• Subject ref not present in the leaderboard → returns null.
• Upstream cachedFetch rejects (so getLikesLeaderboard returns null) → getTopLikedRank also returns null.

These are cheap to add and would protect the ?? null fallback on line 252 of server/utils/likes-leaderboard.ts from a future refactor.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/server/utils/likes-leaderboard.spec.ts` around lines 280 - 295, Add
two tests in test/unit/server/utils/likes-leaderboard.spec.ts for
getTopLikedRank: (1) mock cachedFetch to resolve to a leaderboard that does NOT
include the queried subjectRef (use cachedResult with leaderBoard array missing
the entry) and assert getTopLikedRank(createEvent(cachedFetch), '<subjectRef>')
returns null; (2) mock cachedFetch to reject (vi.fn().mockRejectedValue(new
Error(...))) so getLikesLeaderboard returns null, then assert
getTopLikedRank(createEvent(cachedFetch), '<subjectRef>') returns null;
reference getTopLikedRank, getLikesLeaderboard, createEvent and cachedFetch when
adding these specs.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes